@Firestorm980 thanks for the PR! Could you please fill out the PR template with description, changelog, and credits information so that we can properly review and merge this?

👋🏼 @dshanske would love your review here as well

Will do

It looks good to me. Makes me think I should just give in and write a block compatible version...but...maybe this will inspire someone to submit a PR or two. To be honest. the concept of the plugin is a nice and simple...store and display links philosophy.

@jeffpaul I can replicate the same issue with the PR as mentioned by @iamdharmesh

@jeffpaul I could also replicate what @iamdharmesh mentions.

Currently, when using the Classic Editor, the action to set the syndication links is only triggered when the "Post to X/Twitter" button is clicked, and not when a new post is published, as it is only called in the $('#tweet_now').on('click') event. To trigger when the post is published, the logic will need some refactoring, because on publish, WordPress typically triggers a full page reload, causing the JavaScript context to be reset. Similarly, when we are on the Block Editor, the respective function is called only on the retweet handler.

In my opinion, there are the following adjustments that could be made:

1. The logic that handles the updating of the links could be unified to an extend, to avoid duplication and have a single source of truth as much as possible (right now a big chunk of it is being duplicated in two different files).
2. Apart from the existing actions, it should also be called on post publish, and ideally work for both the Block Editor and the Classic Editor. It's just that these two modes might need different handling.
3. The logic that updates the fields should also be amended so that if there is already an empty input, to use it first, before starting to append new inputs.

I've started working on the above on my local setup but it will take some time. I will try to find some next week, and push a POC with my suggestions.

Happy to accept anything upstream if it would help

Over the past few days, I spent quite a bit of time debugging and ended up hitting the same conclusions that @gsarig mentioned above.

In my own environment, I initially noticed that calls to \Syn_Meta::add_syndication_link would fail to be triggered because the if ( method_exists( 'Syn_Meta', 'add_syndication_link' ) ) check evaluated to false at the wrong time (likely a race or plugin load order issue). Essentially, the Syndication Links plugin’s code wasn’t available early enough for Autoshare for Twitter to call it reliably from it's codebase.

After digging deeper, I also discovered that Syndication Links itself attempts some integration along similar lines (though it has some additional issues, which I documented in the PR I just submitted upstream. Once I resolved that conflict, I created a separate class to have a single source of truth for handling syndication links, and also extended the autoshare_for_twitter_post_tweet_status_updated hook to pass in the $post_id and the $tweet_meta array. That way, any function that’s hooked into that action can take those parameters and manage its own integration flow. In this case, we use them to save the tweet URLs into Syndication Links plugin whenever a post is published or retweeted.

However, I’m still seeing a puzzling behavior when the post is first published:

update_metadata( $type, $id, 'mf2_syndication', $links ) here logs a success result, but the actual mf2_syndication metakey doesn’t appear in the database table until the second time I send a tweet from the WP post (i.e., upon retweeting).

I temporarily added debug output in \Syn_Meta::add_syndication_link which confirms that after the first publication, the new link is saved and retrieved correctly, but it simply doesn’t show up in the wp_postmeta table when inspecting it manually, until I retweet from the "Post to X/Twitter" custom message box. After the retweet, the mf2_syndication metakey is indeed created and includes both the first and second tweet links.

Here’s the relevant portion of \Syn_Meta::add_syndication_link that I used to debug. You can see I added multiple error_log() calls to trace what is stored and when:

// Log the final state before update
error_log( 'FINAL UPDATE METADATA CALL - Type: ' . $type );
error_log( 'FINAL UPDATE METADATA CALL - ID: ' . $id );
error_log( 'FINAL UPDATE METADATA CALL - Meta key: mf2_syndication' );
error_log( 'FINAL UPDATE METADATA CALL - Links: ' . print_r( $links, true ) );

// Let's check if the meta key already exists
$existing_meta = get_metadata( $type, $id, 'mf2_syndication', true );
error_log( 'EXISTING META BEFORE UPDATE: ' . print_r( $existing_meta, true ) );

$result = update_metadata( $type, $id, 'mf2_syndication', $links );
error_log( 'UPDATE METADATA RESULT: ' . ( $result ? 'true' : 'false' ) );

// Double check if it was actually saved
$check_meta = get_metadata( $type, $id, 'mf2_syndication', true );
error_log( 'META AFTER UPDATE CHECK: ' . print_r( $check_meta, true ) );

return $result;

Here is the first metadata update call (happening immediately on post creation and the first tweet). Notice how it says "UPDATE METADATA RESULT: true" and "META AFTER UPDATE CHECK" logs out the correct link:

[06-Jan-2025 03:12:17 UTC] BEFORE update_metadata
[06-Jan-2025 03:12:17 UTC] FINAL UPDATE METADATA CALL - Type: post
[06-Jan-2025 03:12:17 UTC] FINAL UPDATE METADATA CALL - ID: 119
[06-Jan-2025 03:12:17 UTC] FINAL UPDATE METADATA CALL - Meta key: mf2_syndication
[06-Jan-2025 03:12:17 UTC] FINAL UPDATE METADATA CALL - Links: Array
(
    [0] => https://twitter.com/10uptestdev/status/1876103553657549024
)

[06-Jan-2025 03:12:17 UTC] EXISTING META BEFORE UPDATE:
[06-Jan-2025 03:12:17 UTC] UPDATE METADATA RESULT: true
[06-Jan-2025 03:12:17 UTC] META AFTER UPDATE CHECK: Array
(
    [0] => https://twitter.com/10uptestdev/status/1876103553657549024
)

Then, here’s the second update call (when I do a retweet via the "Post to X/Twitter now" UI, sending out the second tweet). This time, the logs show that it retrieved the array containing the first link, appends the second link, and again says update_metadata is successful. At this point, the row does exist in the wp_postmeta table, and it includes both tweet links:

[06-Jan-2025 03:12:17 UTC] BEFORE update_metadata
[06-Jan-2025 03:12:17 UTC] FINAL UPDATE METADATA CALL - Type: post
[06-Jan-2025 03:12:17 UTC] FINAL UPDATE METADATA CALL - ID: 119
[06-Jan-2025 03:12:17 UTC] FINAL UPDATE METADATA CALL - Meta key: mf2_syndication
[06-Jan-2025 03:12:17 UTC] FINAL UPDATE METADATA CALL - Links: Array
(
    [0] => https://twitter.com/10uptestdev/status/1876103553657549024
    [1] => https://twitter.com/10uptestdev/status/1876104472721764863
)

[06-Jan-2025 03:12:17 UTC] EXISTING META BEFORE UPDATE: Array
(
    [0] => https://twitter.com/10uptestdev/status/1876103553657549024
)

[06-Jan-2025 03:12:17 UTC] UPDATE METADATA RESULT: true
[06-Jan-2025 03:12:17 UTC] META AFTER UPDATE CHECK: Array
(
    [0] => https://twitter.com/10uptestdev/status/1876103553657549024
    [1] => https://twitter.com/10uptestdev/status/1876104472721764863
)

I'm attaching screenshots below to give greater visual context and support my reproduction:

1st tweet - Missing mf2_syndication metakey:

2nd tweet - Saves the mf2_syndication metakey:

I’m not sure if this is related to a save-post race condition, or if some other part of the Syndication Links plugin lifecycle is rolling back metadata changes during the first publish, but I’m looking into that further. If anyone else can replicate this behavior or has ideas on what might be interfering with the creation of that metakey on first publish, please let me know!

In the meantime, feel free to test what’s currently in the PR—I’d love to see if others get the same results or can cast some light on this odd behavior.